最後一天了我們來快速的 Review 一下實作結果跟起初設定的目標

目標

首先來看看我們一開始訂的需求

需求:

• 7*24 提供服務
• 離峰時段只有少量的使用者 RPS ≤ 10
• 每個月會有一次的熱門票務 RPS ≤ 3000 持續 5 分鐘

預算:

• 期望是能夠壓在 100 USD/Month

實際

我們是否有達到當初設定的目標呢? 我們一個一個來看看

• 7 * 24提供服務
  這個應該沒什麼爭議使用雲端服務絕對可以達到很高的 SLA
• 峰值 RPS ≤ 3000
  根據我們最終壓力測試的結果 最高 RPS 有道 2400 左右，我們的系統是可以承受到 3000 絕對是沒問題的。
• 100USD/Month
  我們的專案大約開啟半個月 預估金額是 47.93USD，如果開啟一個月的話是在 100USD 以內沒錯的*

大致上我們當初設定的目標都是有達到的。

優化

雖然我們有達到當初設定的目標，但是否還有甚麼地方能夠優化增加系統效能，或是減少成本呢?

效能

針對售票 API 的部分，我們目前還是會跟 Redis 重複進行交互 4 次，每次的交互其實都會有一定的網路延遲，我們可以嘗試將與 Redis 交互的部分全部都改成 Lua Script，打包好一次送給 Redis 讓所有的判斷邏輯都在 Redis 內部完成，這樣可能可以再提升一些購票 API 的效率。

目前 Process Service 消化 Pub/Sub 推送過來的 Message 速度過慢，雖然資料不會丟失但實測，要消化完 50000多張票就需要 2個小時以上，還有很大的進步空間，可以考慮把 Pub/Sub 由 Push Mode 改成 Pull Mode 在想辦法觸發 Process Service 去 Pull Message 批次的寫入資料庫，應該能夠大幅優化 Process Service 消化的速度

費用

費用的部分，我們為了開發測試方便有啟用一台 GCE 來協助我們由 local 連線到 Redis 這台機器如果後續沒有需要使用到可以先進行關機或是直接刪除該資源，進一步節省部分的費用。

心得

非常迅速的 30 天就過完了，這是第一次參加鐵人賽，我並不是個積極上進的人也不太擅長寫作，在同事的鼓勵之下我還是一起報了這次的鐵人賽的團體組，其他夥伴寫的文章品質都比我高很多我只求能夠順利完賽不要拖累團隊實在有些慚愧，起初規劃其實除了後端 API 以外原本想要在做一個類似儀表板的畫面透過 Websckoet 來呈現及時座位狀態，但我太天真了沒有事先做好實作的專案，每天一邊實作一邊寫文章完全是來不及，下次我可能會直接先做好全部的實作再來一步步地說明跟撰寫文章或是直接換個理論性質的主題專心練習寫文章不實作了 XD。

日常我沒有做紀錄的習慣，筆記也大多都是一大堆的範例程式碼跟指令，能夠寫完這 30 天對我來說是一種鼓勵，其中有一篇文章還有人留言問問題並表示他真的有學習到新的東西，讓我感覺到我寫的文章是真的能夠給人帶來幫助的，很慶幸我鼓起勇氣參加了第一次的鐵人賽，期許未來能夠養成寫作或是紀錄的習慣，讓我的寫作能力能夠逐步的提升。